DevelopersIO 2021 Decadeで俺が考える「ユーザーにちゃんと使用されるダッシュボード」について語りました #devio2021

「俺が考える最強のダッシュボード」を作ったのに使われない…という経験をお持ちの方、ぜひ御覧ください

DevelopersIO 2021 Decade

#イベント

#資料公開

#Looker

#Tableau

さがら

2021.10.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

さがらです。

2021年10月13日に開催されたDevelopersIO 2021 DecadeのDAY5：DATA ANLYTICS DAYで、俺が考える「ユーザーにちゃんと使用されるダッシュボード」について語りますというタイトルで登壇しました。

本ブログでは、この登壇内容についてまとめたいと思います。

登壇概要

概要

昨今LookerなどのBIツールは第3世代BIと呼ばれることもありますが、第1世代～第3世代のどのBIツールでも共通して「ダッシュボードを作ったけどユーザーに使われない」という課題があると感じています。そこで、このセッションでは私のこれまでの経験に基づいた「ユーザーにちゃんと使用されるダッシュボード」についてまとめ、お話します。

登壇資料

ダッシュボードが使われない問題とは

ダッシュボードを作る時、楽しくて細部まで拘ったり、BIツール固有の表現なども用いて、「これだ！」と自分が満足する最強のダッシュボードを作った経験のある方もいるのではないでしょうか。

しかし、そんなダッシュボードを実際にユーザーに公開すると、公開直後はウケがいいのですが、数日～1週間程度経つと、全く見向きされなくなる、そんな経験もないでしょうか。

これが、「ダッシュボードが使われない問題」です。

ちゃんと使われるダッシュボードとは

ダッシュボードがちゃんと使われるには、「確認➟分析➟アクション」のサイクルをグルグルと回すことができるダッシュボードであることが重要だと私は考えています。

より具体的には、作成したダッシュボードをユーザーが定期的に確認し、現在の状況を把握して分析して必要な施策を考え、その後に考えた施策を実行に移す、という一連のプロセスをグルグルと回していきます。

1回施策を実行したあとも、その施策の効果を確かめるためにダッシュボードをもう一度確認して、効果があったかを把握して、また別の施策が必要であれば実行する、という流れになると思います。

こちらのスライドでは「確認➟分析➟アクション」のサイクルを一般化して考えるため、家計簿アプリを例として説明しています。家計簿アプリの多くは、収支の状況を確認するためのダッシュボードを提供しています。

まず、毎月の始めに先月の支出をダッシュボードで確認するとします。

そしてダッシュボードを見て分析を行ったのですが、先月の出費の内、衣類費がとても高く、服にお金をつぎ込んでしまったことがデータとしても明らかになったとします。ということで、今月は服にお金を使わない、我慢する、という施策を考えて、実行することにしました。

その後、また一ヶ月後の月初に同じダッシュボードを見て、ちゃんと服を買うのを我慢できたか、我慢できているのに出費が多い場合は何が多いのか、ということを分析して、必要に応じて別の施策を打っていくことになります。「確認➟分析➟アクション」のサイクルが確立しているのがわかりますよね。

このように、日常生活でも行うことが出来る「定期的な確認➟分析➟アクションを行う」のサイクルを、実際のビジネス・業務でも実践すれば良いのです。

ダッシュボード作成＆運用で必要な５つの施策

しかし、前述の家計簿アプリの例は最初からダッシュボードが用意されているから出来るのでは…と感じる方もいるのではないでしょうか。

それはおっしゃるとおりで、実際のビジネスにおいては自分たちでダッシュボードを作らなくてはいけません。

そこで、「確認➟分析➟アクション」の循環が確立されたダッシュボードを作って実際に運用していくにあたり、5つの施策にまとめてみました。次章以降でそれぞれ詳細に説明します。

施策その１：5W1Hに基づいた設計をしよう

改めて5W1Hとは、When、Where、Who、What、Why、Howをまとめた略称のことです。ダッシュボードの作成前に5W1Hを定義しておくことで、可視化すべき指標や、ダッシュボードを作る目的が明確になります。

このスライドでは、前述の家計簿アプリを例にして5W1Hを考えています。以下、5W1Hを考える際の注意点を記します。

When：いつ使用されるのか、具体的な時間を示しましょう。定例会で確認するならば、その定例会をWhenに指定しても良いでしょう。
Where：どこでを見るのか、具体的な場所を示しましょう。最近だとSlackなどのチャットアプリとの連携に強いBIツールもあるので、Slackで見ることをWhereに設定しても良いと思います。
Who：誰が見るのか、具体的な人物を示しましょう。注意点としては、具体的に誰か特定できるようにしましょう。（悪い例：〇〇部の人）
What：何を確認・分析するのかを示しましょう。
Why：何のために使用されるダッシュボードか、示しましょう。このWhyが具体的に出てこない場合、そのダッシュボードはそもそも必要なのか、ということに繋がってきます。
How：どのように使用されるダッシュボードか、示しましょう。このHowで決めた内容がダッシュボードのベースとなるので、ダッシュボードのイメージが出来るようにHowを設定すると良いと思います。

一方で注意点として、自分の妄想だけで5W1Hを定義すると、使う人と場面が考えられていないので、そのダッシュボードはほぼ使用されなくなります。

必ずWhoで定めた人に対してヒアリングをして残りの4W1Hを決めていきましょう。定期的にヒアリングを行うことで、BIツール自体の普及効果もありますし、組織にデータ活用を行う文化を醸成することも出来ます。

施策その２：アクションに繋がる指標を可視化しよう

まずアクションに繋がる指標とは、ダッシュボードを見ることで「具体的なアクション」に紐づく指標のことです。

営業的な観点だと、前回のやり取りから1ヶ月経過していると判明した顧客への再連絡、エンジニア視点だと、運用しているサーバーやソフトウェアが異常値を出していることを見た上でのリカバリー作業、といった内容が該当します。

基本的にダッシュボードは、値を見て「へー」と感じるだけでは何も意味がなく、値を見て何かしらのアクションに繋がるように作るべきだと、私は考えています。

可視化する指標として、悪い例を2つ説明します。

1つ目は、今あるデータから算出できる指標をがむしゃらに可視化することです。何の目的や意図もなく可視化した指標は、本来見てほしい指標の理解を妨げる原因になりえます。 5W1Hに則って、可視化すべき理由が明確な指標をダッシュボードに入れるようにしましょう。

2つ目は、「売上」「利益」といった、組織目標レベルのKGIに該当する指標だけを可視化することです。確かに売上や利益は企業にとって最重要の指標なのですが、その値を見ただけでは次にどうしていいかわからないと思います。

可視化する指標について、良い例を説明します。

1つ目は、値を見て誰がどんなアクションをするか明確な指標を可視化することです。これは先程説明しました5W1Hを定義することで、誰が何のために見る指標か明確になりますので、5W1Hの定義がやはり重要です。

2つ目は、KPIツリーを作りKPIを細分化して、アクションに繋げやすい細分化された指標を可視化することです。 KPIツリーとは、KGI、Key goal Indicatorである組織目標を、KPI、Key Performance Indicatorsとしてより細かな中間目標に分解して紐付けていった図のことです。

このスライドの右側には小売業のとても簡単なKPIツリーを載せていますが、KGIに該当する頂点の「売上」をあげるためには、「購入点数を増やす」「来店数を増やす」「会員数を増やす」ということが必要だとわかります。

施策その３：ユーザーへの負荷が少ない設計を心がけよう

まず「ユーザーへの負荷が少ない設計」とは、ユーザーがダッシュボードの内容を容易に理解することができるように、ダッシュボードの設計をすることです。なぜこの「ユーザーへの負荷が少ない設計」が必要なのかと言うと、大きく２つの理由があります。

1つ目は、人間がダッシュボードを閲覧してその内容を理解することは、何かしらのエネルギーを消費する行為であるためです。特にはじめて見るダッシュボードで、表示されているグラフの数が多すぎたりフィルタの数が多すぎて使用するのに負荷がかかると、人によっては「使いづらい」と投げ出してしまう人もいるかもしれません。

2つ目は、エネルギーの消費が少ないダッシュボードであると、ユーザーは閲覧時の抵抗感が減り、そのダッシュボードを使い続けてくれる可能性が高まるためです。

この発表では、グラフベースでの例と、ダッシュボードベースでの例、２つ紹介しました。詳細は下記の2枚のスライドよりご確認ください。

施策その４：数値に異常があれば最優先で対応しよう

「数値の異常」とは、ダッシュボードで表示している数値が正しくない状態を意味しています。例としては、本来100と表示したいのに、レコードの重複によるダブルカウントで200と表示されてしまったり、というケースなどがあげられます。

なぜこの数値の異常があったときに最優先で対応しないといけないのかというと、値が合っていないダッシュボードの場合、ユーザーはすぐにそのダッシュボードを切り捨ててしまうことがあります。特に、まだダッシュボードやBIツールが組織に馴染んでいないときには、「なんだこのダッシュボード、使えんな」、のように感じられるリスクが高いと思います。

一方で業務にダッシュボードやBIツールが馴染んでいたときに、数値の異常が発生したとして、そのリカバリを後回しにしてしまうと、ユーザーからのダッシュボードとBIツールへの信頼はがた落ちします。そのため、「数値の異常」が発生したら最優先で対応しましょう！

続いてどうやって数値の以上を防ぐのか、データフロー面での防止策の説明となります。

このスライドの下部では、元々のデータソースからBIツールでの使用に至るまでのデータフローを表しており、各矢印がデータを加工して次のフェーズに移るタイミングとなっています。特に、この図の赤矢印のタイミングで、異常なデータがあったらエラーを出力し処理停止して、管理者へ通知することが望ましいと、私は考えています。

この赤矢印のタイミングで、何かしらのETL・ELTの製品を使っていればエラーが発生した時、設定した方法で通知できるようになっていると思います。（Fivetranやdbtなど）

一方で注意しないといけないときは、自分でPythonなどのプログラミング言語を用いて、この図の赤矢印に該当する処理を作るときです。その理由は、自由に処理を記述できるので、データが正しいことを検証せずに次のフェーズに進めてしまうことが可能なためです。もし異常なデータを次のフェーズにすすめてしまった場合、BIツールが参照するデータはあっという間によごれてしまいます。

そのため、自分で処理を作るときにはデータが正しい内容であるかチェックする処理を入れたり、エラーが発生したら処理が止まるような方法を取りましょう。例えば、昨今データ関係でよく使用されるPythonでは、データを検証するライブラリが何種類かあると思いますので、有効活用できると良いと思います。

データを検証できるPythonライブラリの例
- Cerberus
- pandera

次は、BIツール上での対策の話になります。

先程のデータフローでの対策を施して参照先のテーブルが正しければいいんじゃないの、と思う方もいるかもしれませんが、そんなことはありません。最終的に可視化する指標の計算ロジックはBIツール上で組むことが多いです。そのため、テーブルの値が正しくても、最後にBIツール上で組んだロジックが正しくないと値がおかしくなってしまいます。

そこで、見るべきポイントを２つ説明します。

1つ目は、集計方法についてです。基本的にBIツールでは、合計や平均など、何かしらの集計方法を指定すると思います。ここが合っていないことには根本的に値がズレてしまうので、まずは集計方法を確認しましょう。

2つ目は、何かしらIFやCASEなども併せて条件文を盛った計算ロジックを組んでいる場合です。これは正直試行錯誤して試すしか無いですが、これまでに同様のロジックで集計したことがあれば、その実績値と比較するのもよいと思います。